Code Review

Summary: Solid targeted fix. The fulfillOnce one-shot guard is exactly right for this race, and the implementation is a faithful copy of the already-proven pattern from testContinuousCaptureLifecycle. My only flag is the unrelated submodule bump — worth a quick sanity check before merging.

The fix (test-only change — KeyboardCaptureTests.swift)

Correct and consistent. The NSLock + didFulfill guard pattern is already used in three other places in this file (lines ~181, ~435, ~475). Applying the identical pattern here is the right call over introducing a new idiom.

The comment is also justified: this is a non-obvious cross-call race (callback vs. asyncAfter fallback) that bit a real CI run — the why belongs in the code.

One minor observation: XCTestExpectation has assertForOverFulfill = false which can suppress this crash without a manual guard, but that's an additive change to an existing pattern. Consistency with the sibling tests is more valuable here than cleverness.

Kanata submodule bump (External/kanata: 6a05a4a → 49b856a)

This diff was not mentioned in the PR description, and the stated scope is "Test-only; no production code changes."

A submodule bump to the kanata fork (malpern/kanata, branch keypath/bundled) is a production-facing change — it affects what binary ships in the app bundle. A few things to verify:

1. Is this intentional? If the bump is real work, it should be described and reviewed on its own merits.
2. If it's accidental (branch was cut from a working tree where the submodule was already ahead), reverting the submodule to 6a05a4a3f before merging keeps the PR scope clean.
3. Per CLAUDE.md kanata fork safety rules: confirm the bump is a fast-forward on keypath/bundled and that no commits are lost. git log --oneline 6a05a4a..49b856a inside the submodule will show what's new.

Verdict

The test fix is approved — minimal, correct, zero production risk, and unblocks the coverage lane.

The submodule bump needs a quick clarification: intentional or accidental? If accidental, revert it and this is a clean merge. If intentional, a sentence in the PR description and a fast-forward verification are all that's needed.

Rebuilt this branch as current master + the single fix commit (cherry-pick of 3e7aa2a). The previous build-and-test failure was the stale base: RemapEndToEndTests failures reproduced only against the old base and pass on current master (verified locally). Both KeyboardCaptureTests and RemapEndToEndTests pass locally on the rebuilt branch. Babysitting CI to merge.

Follow-up after rebuild

Thanks for the cherry-pick rebuild — cleaner base should take care of the RemapEndToEndTests noise.

One thing to double-check before merging: the External/kanata submodule bump (6a05a4a → 49b856a) is still in the diff after the rebuild. If the cherry-picked commit doesn't touch the submodule, this means master already has the submodule at 49b856a and the diff is a no-op. If master is still at 6a05a4a, the bump is tagging along unintentionally and should be reverted to keep the PR scope to the test-only fix.

Quick check:

git -C External/kanata log --oneline 6a05a4a..49b856a

If that returns nothing (already on master), all clear. If it shows new commits, revert the submodule before merging.

The test fix itself remains approved — the fulfillOnce guard is correct and the rebuild should make CI green.

Root cause of the lane failure found: the original commit accidentally carried an External/kanata submodule downgrade (6a05a4a → 49b856a) from its stale worktree — silently reverting the MAL-57 Layer 2 engine bump (#885) and breaking RemapEndToEndTests in the full lane (CI builds the old simulator from the reverted pin; locally the newer submodule checkout masked it). Amended to keep the pin at 6a05a4a. Also folded in the Neovim pack 19-binding fix for testPackBindingsMatchCollectionMappings (full-lane-only invariant that #893's standard run never executed). Polling CI.

Code Review

Overview

This PR contains two changes:

1. Test fix (KeyboardCaptureTests.swift): Applies the existing one-shot fulfillOnce lock pattern to testSingleKeyCaptureLifecycle, fixing a double-fulfill XCTest crash that killed the full-coverage runner.
2. PackRegistry expansion (PackRegistry.swift): Expands the neovimTerminal pack from 7 to 19 bindings, adding e, 0, 4, g, /, n, x, r, d, and o.

Test Fix — KeyboardCaptureTests.swift

Verdict: Correct and well-motivated. The fix is a direct transplant of the guard pattern already proven in testContinuousCaptureLifecycle.

• The lock + didFulfill bool correctly prevents any second fulfill() call regardless of which path (capture callback vs. asyncAfter fallback) wins the race.
• The comment accurately describes the failure mode and when it was first observed.
• The three fulfill sites (no-permission path, permission-with-keys path, permission-without-keys path) are all consistently updated.

Minor observation — testEmergencyMonitoringLifecycle (not changed, but adjacent):

capture.startEmergencyMonitoring {
    emergencyTriggered = true
    expectation.fulfill()      // path A
}
DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {
    if !emergencyTriggered {
        expectation.fulfill()  // path B
    }
}

Path A and path B both run on the main queue, so the !emergencyTriggered check is sequentially safe. However, if path A fires and path B also fires (e.g. callback fires twice due to some edge case), this test has no double-fulfill protection. Not an immediate issue since the emergency monitor callback shouldn't fire in the CI environment, but worth applying the same fulfillOnce guard next time this file is touched.

PackRegistry Change — PackRegistry.swift

Verdict: Mostly good, three items worth reviewing.

1. e and w map to the same output (A-right)

PackBindingTemplate(input: "w", output: "A-right", title: "W → Word forward"),
PackBindingTemplate(input: "e", output: "A-right", title: "E → End of word"),

Vim distinguishes w (jump to start of next word) from e (jump to end of current word). On macOS Option+Right always lands at the end of the next word, so there's no perfect mapping for both — but having two keys with identical behavior may confuse users who expect different behavior. Consider either dropping e to reduce clutter, or picking a different approximation and documenting the limitation in the title/description.

2. g is titled "Document top/bottom" but only maps to M-up (top)

PackBindingTemplate(input: "g", output: "M-up", title: "G → Document top/bottom"),

This will take you to the top but not the bottom. If the intent is that G (shift+g in Vim) is the bottom binding, there's no separate binding for it here. Either add G → M-down, update the title to "G → Document top", or add a note clarifying the single-direction behavior.

3. shortDescription is stale

"Hold Leader for Neovim-style motions inside approved terminal apps: h/j/k/l arrows, w/b word jumps, 0/$ line ends, undo, yank, and put."

This now undersells the pack by ~12 bindings (e, g, /, n, x, r, d, o are unmentioned). Not a runtime bug, but users reading the description won't know about find, redo, delete-word, or open-line-below.

Summary

The test fix alone is mergeable. The PackRegistry items are low-severity but the g title is the most likely to confuse users and worth fixing before merge.

Code Review — PR #891

Overview

This PR bundles three separate changes: a test fix for an XCTest double-fulfill crash, a CI cache-invalidation improvement, and 10 new bindings added to the neovimTerminal pack in PackRegistry.swift.

✅ Test Fix — KeyboardCaptureTests.swift

The fulfillOnce one-shot pattern is correct, idiomatic, and exactly mirrors the pre-existing fix in testContinuousCaptureLifecycle. NSLock is the right choice here: lightweight and interrupt-safe for a short critical section.

One style note: the inline comment block spans 4 lines, which is more than CLAUDE.md's "one short line max" guidance. The key detail to preserve is why (two fulfillment paths, loser lands post-test), not the incident history. Consider collapsing to a single line:

// asyncAfter and startCapture callback can both fire; one-shot guard prevents post-test fulfill crash

✅ CI Fix — .github/workflows/ci.yml

Solid fix. Gating cache reuse on a SHA stamp is the correct approach for a persisted self-hosted runner workspace. The stamp is written after the build succeeds, so a mid-build failure won't poison the cache.

One minor improvement: the stamp file write could be wrapped in a subshell or conditioned to only write on full success to guard against partial cp failures:

cp ... && cp ... && chmod ... && echo "$EXPECTED_ENGINE_SHA" > build/ci-kanata-cache/engine-sha

Currently a chmod failure would leave the stamp unwritten (fine), but a future reorder could silently write a stamp for a partial cache. Not a current bug — just defensive hygiene.

⚠️ PackRegistry Changes — Misleading PR Description

The PR body states "Test-only; no production code changes." This is incorrect. PackRegistry.swift is a production source file, and adding 10 bindings to the neovimTerminal pack is a functional change that affects what users see in the overlay/HUD.

This deserves at minimum a sentence in the PR description explaining the motivation (e.g., "also aligns the pack's 19 bindings with the existing 19-mapping neovimTerminal collection to unblock testPackBindingsMatchCollectionMappings").

Semantic concern — input "4" / title "$ → Line end":

PackBindingTemplate(input: "4", output: "M-right", title: "$ → Line end"),

In vim, $ is the key for line-end but the physical key is Shift+4. If input drives HUD display, users will see key 4 labeled "$ → Line end" — either the input should be "$" or the title should be "4/$ → Line end". How the neovim reference overlay renders the input field determines whether this is a visual bug or not.

Multi-key output:

PackBindingTemplate(input: "o", output: "M-right ret", title: "O → Open line below"),

Since the neovimTerminal collection is an educational reference (excluded from kanata config generation), multi-key output strings won't be applied as kanata mappings. Confirm this renders correctly in the HUD — if it's displayed verbatim as M-right ret rather than a friendly label, it would look odd.

Summary

The core test fix is ready to merge. Address the PR description inaccuracy at minimum, and clarify the "4" vs "$" input semantics before merging the pack changes.

Code Review

Overview

This PR fixes a latent XCTest suite-killer: testSingleKeyCaptureLifecycle could double-fulfill an expectation when both the capture callback and the asyncAfter fallback fired, crashing the runner mid-suite and preventing coverage generation. The PR also adds a SHA-based kanata cache-invalidation guard in CI, expands the NeoVim terminal pack with 10 new bindings, and skips a flaky simulator-based end-to-end test on CI.

Core fix — KeyboardCaptureTests.swift ✅

The fulfillOnce pattern (NSLock + bool guard) is applied correctly and matches the established pattern in testContinuousCaptureLifecycle exactly. Thread safety is sound: defer { lock.unlock() } prevents the lock leaking on the early-return path. The comment is precise about the failure mode (async block fires late, after test cleanup, into a completed expectation).

No issues here.

CI kanata cache fix — ci.yml ✅

Stamping the cache directory with the submodule SHA and comparing before reuse is the right approach for a persistent self-hosted runner workspace. The debug log lines now include the actual SHAs, which is a nice operational improvement.

Confirmed that CI_ENVIRONMENT=true is already exported in both ci.yml and coverage.yml, so the downstream skip in RemapEndToEndTests will fire correctly on CI.

RemapEndToEndTests CI skip — acceptable with caveats ⚠️

Using XCTSkip rather than a compile-time exclusion is the right mechanism, and the comment points to #896. Two things to watch:

• The skip message says "simulator yields no mappings" — that is a separate functional bug from the cache-staleness bug that motivated the PR. Worth confirming in RemapEndToEndTests fails on the self-hosted CI runner (simulator returns no mappings) — passes locally with identical engine #896 whether fixing the stale-binary cache (the ci.yml change above) actually resolves it, or whether the simulator has a separate runner-environment issue.
• Until RemapEndToEndTests fails on the self-hosted CI runner (simulator returns no mappings) — passes locally with identical engine #896 lands, RemapEndToEndTests has zero CI coverage. Make sure the installed-app smoke path genuinely covers the same paths these tests exercise.

NeoVim terminal pack bindings — questions on vim semantics 🟡

Adding 10 bindings to align the pack with the collection's 19 mappings is fine mechanically, and testPackBindingsMatchCollectionMappings will keep count in sync. A few semantic notes:

"M-right ret" for O → Open line below: This is a space-separated multi-key output, which AppConfigGenerator correctly wraps as (macro M-right ret). Valid kanata syntax. ✅

r → M-S-z "R → Redo": In Vim, r is "replace character" (single-key overwrite), not redo. Ctrl+r is vim's redo. Repurposing r for macOS Cmd+Shift+Z will surprise muscle-memory vim users who reach for r expecting replace mode.

d → A-bspc "D → Delete previous word": In Vim, d is the delete operator (dw, dd, etc.). Mapping it to Alt+Backspace (backwards word-delete, macOS convention) is a significant semantic departure. The existing x → del mapping for "delete character" is closer to vim's x, so there is a mix of conventions here.

g → M-up "G → Document top/bottom": Cmd+Up goes to the top of the document, not bottom. Vim's G goes to the bottom; gg goes to the top. The title is slightly misleading — consider "G → Document start" to match what the key actually does, or map g to M-up and add a separate shifted binding for M-down.

4 for $ → Line end: Input key is 4 (unshifted). This avoids needing Shift but departs from vim finger memory. If this is an intentional simplification, a brief comment would clarify the intent.

These are subjective UX tradeoffs, not bugs — but they affect the educational value of the pack for actual vim users. Worth a deliberate decision rather than leaving them ambiguous.

Summary

The core fix is ready to merge. The pack binding semantics for r, d, and g are the main open question.